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ABSTRACT 


In  this  paper  we  consider  a  resource  allocation  problem  which  is  local 
in  the  sense  that  the  maximum  number  of  users  competing  for  a  particular 
resource  at  any  time  instant  is  bounded  and  also  at  any  time  instant  the 
maximum  number  of  resources  that  a  user  is  willing  to  get  is  bounded.  The 
problem  may  be  viewed  as  that  of  achieving  matchings  in  dynamically  changing 
hypergraphs,  via  a  distributed  algorithm.  We  show  that  this  problem  is 
related  to  the  fundamental  problem  of  handshake  communication  (which  can  be 
viewed  as  achieving  matchings  in  a  dynamically  changing  graph,  via  distributed 
algorithms)  in  that  an  efficient  solution  to  each  of  them  implies  an  efficient 
solution  to  the  other.  We  provide  real-time  solutions  to  the  resource 
allocation  problem  (that  is,  we  give  distributed  algorithms  with  real  time 
response) .  We  make  essential  use  of  probabilistic  techniques  as  first  used 
by  [Rabin,  80b] ,  where  processes  are  allowed  to  make  independent  probabilistic 
choices.  On  the  other  hand,  no  probability  assumptions  about  the  system 
behavior  are  made.  One  of  our  solutions  assumes  the  existence  of  an  under¬ 
lying  real-time  handshake  communication  system,  as  described  in  [Reif, 
Spirakis,  81].  Our  other  solution  is  based  on  efficient  synchronization  by 
flag  variables,  which  are  written  only  by  one  process  and  read  by  at  most 
one  other  process.  The  special  case  of  equi-speed  processes  is  first 
examined.  Then  we  generalize  to  asynchronous  processes.  Applications  are 
made  to  dining  philosophers,  scheduling  and  two-phase  locking  in  databases. 


I. 


INTRODUCTION 


1.1  The  Resource  Granting  System 

In  this  paper  we  consider  a  resource  allocation  problem  which  is 
local  in  the  sense  described  in  [Lynch,  1980].  The  set  of  resources p 
and  the  set  of  user  processes  U  may  be  infinite  sets.  However,  there  is 
a  limit  to  the  number  of  user  processes  requesting  a  particular  resource. 

We  assume  that  names  of  processes  are  integers.  Resources  are  controlled 
by  a  set  of  granting  processes  R.  Each  granting  process  j  €  R  controls 
a  resource  p(j)  £  p.  We  assume  user  processes  communicate  only  with  those 
granting  processes  for  which  they  request  resources.  (It  is  easy  to  super¬ 
impose  each  granting  process  into  a  requesting  user  process  so  that  U  *  R. ) 

A  system  described  as  above,  is  called  a  Resource  Granting  System 
(RGS) .  The  goal  of  a  RGS  is  to  satisfy  dynamically  changing  user  requests 
for  resource  allocation.  This  is  done  in  a  distributed  way,  by  only  a  local 
communication  between  granting  and  requesting  processes.  An  implementation  of  the 
RGS  determines  the  synchronization  algorithms  that  the  processes  run.  It  is  symmetric 
if  these  algorithms  do  not  depend  on  the  location  of  the  processes  in  the  net¬ 
work.  At  each  time  t>0  the  requests  by  user  processes  U  are  specified 
by  an  adverse  oracle  of,  (which  may  be  an  "enemy"  of  the  resource  allocation 
algorithm,  by  setting  actions  in  the  worst  way  to  increase  the  respone 
time.)  (Note  that  in  practice  no  such  oracle  M  may  exist  but  instead  each 
user  process  is  executing  some  program  which  requires  from  time  to  time  some 
resources  to  be  allocated  to  that  user  process.  The  oracle  ji  is  used  as  an 
artificial  device  for  specifying  worst  case  situations  for  the  resource 
allocation  algorithm.)  ji  also  has  the  capability  to  select  at  time  t*0 
the  schedule  of  the  speeds  of  all  processes  at  all  times  t>0.  The  oracle  .V 
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is  restricted,  to  allow  users  to  keep  asking  for  their  resources  until  they 
are  granted.  We  assume  that  there  is  a  global  time  t  totally  ordering 
events,  but  processes  do  not  have  access  to  it. 

An  RGS  with  priorities  is  defined  to  be  a  resource  granting  system  in 
which  the  requesting  processes  communicate  to  each  resource  granting  process 
a  rational  number  on  the  interval  [0,1],  indicating  the  priority  of  the 
request.  A  priority  greater  than  0  indicates  a  request  for  that  resource. 

These  priorities  can  change  dynamically.  The  processes  of  R  use  the  priori¬ 
ties,  that  the  processes  of  U  communicate  to  them,  to  grant  their  controlled 
resource  with  preference  to  users  of  higher  priority.  This  must  be  done  in  a 
way  avoiding  user  starvation. 

1.2  Complexity  of  an  RGS 

A  process  step  consists  of  either  an  assignment  of  a  variable,  a  test,  a 

logical  or  arithmetic  operator  or  a  no-op.  A  step  is  considered  to  be  a  finite 

time  interval  A  in  which  a  single  instruction  is  executed  instantaneously  at 

the  last  moment  of  A.  Note  that,  by  these  semantics,  there  can  never  be  read- 

write  conflicts  in  the  use  of  flag  variables. 

Let  a  process  be  tame  during  a  time  interval  A,  if  for  any  interval 

A' €  [0,°°),  which  intersects  A  and  is  a  single  step  of  the  process,  then 

I A  *  I  €  [r  ,  ,r  ]  where  r  .  ,  r  are  fixed  real  constants  and 
1  '  min  max  nan  max 

0<r  ,  <r  .  without  loss  of  generality  we  assume  that  r  /r  ,  is  an 
min  max  max  min 

integer.  We  do  not  assume  processes  always  tame,  however,  they  are  supposed 
to  be  tame  in  the  complexity  analysis  of  response  time.  We  require  that,  at 
no  time,  any  granting  process  iCR  simultaneously  grant  the  resource  R(i) 
to  more  than  one  requesting  process.  We  also  require  that,  as  soon  as  a 
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process  jCU  has  got  all  its  required  resources,  then  it  can  keep  them  only 
for  a  time  interval  upper  bounded  by  a  fixed  parameter  (resulting  in  a  bounded 
number  of  its  steps  y,  if  the  process  is  tame).  Let  resources(i)  be  the  set 
of  all  possible  resources  that  a  process  i€U  is  going  to  ever  request,  and 
let  resources^ (i)  be  the  set  of  resources  i  is  requesting  at  time  instant  t. 
Let  k.  be  | resources  (i) | .  For  each  time  t,  the  willingness  digraph  G 

X  f  W  t  V 

is  defined  such  that  if  i €  U  and  j  €  R  and  if  i  requests  or  has  been 

granted  resource  p(j)  at  t,  then  the  edge  i  -*  j  belongs  to  Gfc.  Let  also 

j  ■*  i  if  the  granting  process  j  is  willing  to  allocate  (or  has  granted)  its 

resource  to  user  i.  Let  v  be  the  maximum  valence  of  the  nodes  j  €  R  of 

V 

In  the  following  we  will  assume  at  all  times  t>0  that  v  and  k.  ^ 

t  jL  $  t 

are  above  bounded  by  constants  v,k  respectively  and  that  v  <  k.  This  does 
not  imply  anything  about  the  cardinality  of  the  sets  resources (i)  Vi€u,  which 
could  be  unbounded.  We  also  assume,  as  in  [Lynch,  1980],  that  each  resource 
allocator  j  €  R  has  a  set  available  to  it  of  size  ^v,  containing  the 

names  of  those  processes  willing  to  get  the  resource.  We  assume  this  to  be  a 
primitive  of  our  system  (which  could  be  implemented  by  a  queued  message  system 
or  by  other  means) .  Finally,  we  restrict  any  oracle  oi  so  that  as  soon  as  it 
produces  a  request  for  a  resource  (i.e.,  it  orders  the  appearance  of  the  edge 
i  ■*  j  in  for  i €  U,  j €  R)  it  has  to  insist  on  that  request  until  i 

gets  all  its  requested  resources  at  that  time.  (Note  that  the  relation  * 
can  be  viewed  as  a  time  varying  hypergraph  with  node  set  II  *  U  b  R  and  hyperedge 
set  E  -  { { i }  u  resourcet (i)|  i €  u} .  An  RGS  implementation  dynamically  achieves 
matchings  in  this  hypergraph.  We  allow  probabilistic  RGS  implementations 
where  processes  can  use  independent  random  number  generators. 
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Fix  an  RGS  implementation  which  may  be  probabilistic.  For  each  k 
(0<k<v)  and  oracle  a/  let  the  k -grant  response  be  the  random  variable 
^  giving  the  length  of  the  minimum  interval  A  required  for  any  process 
i €  U  to  have  k  resource  requests  simultaneously  granted,  given  that  i 
requested  these  resources  during  the  entire  interval  A,  with  priority  1, 
and  assuming  that  i  and  all  the  allocators  of  the  resources  requested  by 

\i  within  A  are  tame  on  A.  Let  the  mean  k -grant  response  be 

\ 

Y^  =  max{mean(Yjt  over  all  oracles  >.«/}.  For  each  e  in  [0,1]  let  the 

t-krror  k -grant  response  be  the  minimum  (e)  such  that  for  every  oracle 

Prob(Yk  ^  <  Yk<£)  >  2*  1  -  e 

* 

The  RGS  implementation  is  real  time  if  for  every  k£{l,...,v}  and  for 
every  e6  (0,1],  Yk<£)  >0  and  independent  of  any  global  measure  of  the 

network  (except  v) .  The  network  here  has  as  nodes  the  elements  of  II  and 
each  edge  {u,r}  denotes  that  p(r)  €  resources (u) .  Note  that  if  the  RGS 
implementation  is  real  time,  then  Y^  is  constant,  independent  of  any  global 
measure  of  the  graph  H  of  the  network  (except  perhaps  v) . 

1. 3  Previous  Work 

[Lynch,  1980]  considered  the  problem  of  allocation  of  resources  in  a 
distributed  system.  Her  RGS  implementation  was  a  deterministic,  non- 
symmetric  one  (processes  were  allowed  to  know  the  color  of  each  resource  in 
a  coloration  of  the  resource  graph,  i.e.  the  graph  whose  nodes  are  the 
resources  and  two  resources  i,  j  have  an  edge  between  them  iff 
resource  1 (i)  0  resource-1 (j)  f  0) ,  and  the  communication  system  adopted  was 
a  message  system  requiring  buffered  communication.  [Lynch,  1980]  achieved 
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Y  (H) 

k-grant  response  of  the  order  x<H)‘vA  "T  where  is  the  chromatic 

number  of  the  resource  graph  and  T  is  the  time  required  for  process  communi- 
cation.  Note  that  since  resources  (i)  for  iCU  may  be  unbounded,  in  the 
worst  case  X<H)  can  be  as  large  as  the  number  of  processes  |ll|. 


1.4  Results  of  this  Paper 


We  shall  present  in  Section  3  a  probabilistic  implementation  of  an  RGS 

•  — 

which  has  mean  k-grant  response  Y^  =  0(kv  -T*log  v)  and  t-error  k-grant 


response 


V£)  -  0 


(kvklo<3(c)  T(^)) 


where  T  and  T(e)  are  the  mean  time  and  e-error  response  required  for 

handshake  communication  between  processes  (see  Appendix  for  definitions) . 

In  [Reif , Spirakis  1981],  [Reif,  Spirakis  1982]  handshake  communication 

2  2 

implementations  were  given  with  T  =  0(v  )  and  T(e)  =  0(v  log(l/e)).  Note 
that  these  implementations  achieve  real  time,  thus  the  resulting  RGS 


implementation  is  also  real  time  with  mean 


=  0(kvk+2log  v)  and  Yk(e)  =  o(kv,C+2log 


(iM*))  ' 


However,  any  other  handshake  communication  implementation  would  also  do. 

In  Section  4  we  present  a  basic  way  to  implement  a  real  time  RGS  in 

both  cases  of  equispeed  and  asynchronous  tame  processes.  The  isiplementation 

is  probabilistic.  No  underlying  handshake  communication  system  is  assumed. 

Instead,  the  means  of  synchronization  between  processes  in  U  and  R  are 

flag  variables  (which  are  written  by  just  one  process  and  allowed  to  be 

_  X+l 

read  by  at  most  one  other  process).  The  response  time  has  mean  Y^^OCkv  ) 
and  Yk(c)  -0(kvk+1  log(l/c)). 
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1. 5  Organization  of  Paper 

This  paper  is  organized  as  follows:  Section  2  contains  applications  of 
RGS  to  dining  philosophers,  scheduling,  two-phase  locking  in  databases,  and 
real-time  handshake  communications.  Section  3  discusses  a  real  time  RGS 
assuming  an  underlying  real  time  handshake  communication  system.  Section  4 
discusses  a  real  time  RGS  implementation  by  use  of  flags.  First  an  imple¬ 
mentation  is  discussed  in  which  processes  have  the  same  speeds  but  their 
actions  may  be  relatively  shifted  in  time.  At  the  end  of  Section  4  we 
generalize  our  algorithms  to  the  case  where  processes  are  asynchronous  but 
tame.  Section  5  presents  a  probabilistic  analysis  of  our  algorithms.  The 
Appendix  defines  handshake  communication  systems  and  their  performance 
measures . 


2.  APPLICATIONS 

2.1  Hasty  Dining  Philosophers 

As  a  simple  example,  we  consider  an  interesting  RGS  system  which  we 

call  " hasty  dining  philosophers".  Let  the  requesting  processes  U  be 

distinct  integers,  r  , ...,r  ,  and  the  granting  processes  R  be  0,...,n-l 

0  n-l 

so  that  UflR*0.  The  resources  are  forks  {p(0),  —  ,p(n-l)}.  Each  philo¬ 
sopher  r.  6U  has  resources (r . )  consisting  of  the  forks  {p(r.) ,p(r, ....  .  )}. 

3  3  3  (3+l>modn 

Thus,  the  resource  graph  H  is  a  cycle  of  length  n.  The  "hasty  dining 

philosophers"  has  a  high  level  real  time  RGS  implementation  with  mean  2-grant 

_  2 

response  y2“0(l)  and  e-error  2-grant  response  y2  (e)  *  O(log  (1/e)  ).  The 

low  level  RGS  implementation  gives  Y2  »  0(1)  and  Y2 (e)  ■  O(log(l/C))  . 

Intuitively,  the  RGS  implementation  requires  each  philosopher  r^  to  be  at 


! 


T  ’ 
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any  time  granted  both  forks  of  resource (rj  in  expected  constant  time,  but 
r^  must  be  "hasty”  and  relinquish  these  resources  within  constant  time  inter¬ 
val.  Note  that  for  each  i € {0, . . . ,n-l}  the  granting  process  i  can  be 


placed  within  process  r^,  thus  resulting  in  essentially  only  n  processes. 


2.2  Scheduling 

Suppose  an  acyclic  digraph  D  is  given  with  node  out-degree  <k,  and 
in-degree  <v.  This  graph  can  be  separated  into  levels.  We  assume  processes 
residing  in  the  nodes  of  D  can  operate  only  after  getting  all  their  resources 
(which  reside  at  the  nodes  which  have  no  successors) .  Each  process  operates 
just  once  and  in  a  constant  time  interval  becomes  a  resource  granting  process, 
to  serve  the  next  higher  level.  All  its  successors  are  deleted.  So,  each 
node  is  initially  a  requesting  process  and  after  it  gets  all  its  resources 
once,  it  becomes  a  resource  granting  process.  By  assuming  a  real  time  RGS 
implementation  the  above  system  can  be  processed  in  time  of  the  order  of  the 
depth  of  the  digraph. 


2.3  Two-Phase  Locking  in  Databases 

Two-phase  locking  is  a  concurrency  control  method  in  databases  (see 
the  survey  paper  of  [Bernstein,  Goodman  1980])  with  the  feature  that  as  soon 
as  a  transaction  releases  a  lock,  it  never  obtains  additional  locks.  The 
technique  of  two-phase  locking  produces  serializable  transaction  executions. 
We  propose  in  [Reif,  Spirakis  1982B]  a  technique  to  implement  two-phase 
locking  in  a  distributed  database,  which  is  different  from  any  known  algo¬ 
rithms.  Zn  fact,  it  can  be  viewed  as  intermediate  between  the  techniques  of 
static  and  dynamic  locking.  Our  underlying  assumption  is  that  transactions 
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are  allowed  to  act  on  the  data  only  if  they  got  all  the  locks  requested. 

Let  the  processes  of  the  user  set  U  be  called  transaction  modules  and  the 
processes  of  the  set  R  be  called  data  modules.  If  each  transaction  requests 
to  lock  at  most  k  data  modules  at  a  time  and  if  at  most  v  transactions 
can  compete  for  a  lock  at  a  time  instant  t,  then  a  real  time  RGS  will  result 
in  real  time  lock  allocation  per  transaction.  The  transaction  modules  go 
through  a  "round"  (of  constant  number  of  steps  in  duration)  during  which 
they  communicate  with  all  data  modules  they  want  to  lock.  They  keep  the 
locks  they  get  only  for  constant  number  of  steps  hoping  in  the  meanwhile  to 
get  all  of  them.  If  the  round  finishes  and  they  did  not  succeed  in  getting 
all  the  locks,  then  they  release  whatever  they  got  and  try  again  in  the 
next  round.  Given  the  previously  stated  response  time  y^fE)  for  a  refll- 
time  RGS,  one  can  now  decompose  the  distributed  system  into  a  system  of 
parallel  servers  with  almost  independent  geometrically  distributed  service 
time,  (one  per  transaction  module) .  In  [Reif,  Spirakis,  1982B]  we  then 
analyze  the  transaction  waiting  time,  throughput  etc.,  by  assuming  a  proba¬ 
bility  distribution  in  the  transaction  arrival  rate. 

2.4  Handshake  Communication  in  Real  Time  Via  a  Real  Time  RGS 

We  can  implement  here  handshake  communication  in  the  sense  of  the 
Appendix,  assuming  the  existence  of  a  real-time  RGS.  Assume  that  each  of  the 
processes  j  €  R  control  just  one  resource  called  the  channel  and  when  they 
allocate  this  resource,  we  say  they  open  the  channel.  The  processes  i€U 
are  assumed  to  open  their  channel  when  they  are  granted  their  resource  and  to 
close  their  channel  when  the  resource  is  removed. 

Each  of  the  processes  i€U  have  | resourcet (i)  |  K  1,  so  as  soon  as  any 
process  i €  U  is  granted  one  resource ,  process  i  does  not  coitqpete  for  any 
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other,  until  i  releases  that  resource. 

Given  bounds  v  on  the  processes  i£U  competing  for  the  same  p(j), 
j  €  R  and  a  bound  k<v  on  the  number  of  resources  a  user  is  willing  to  be 
granted  at  any  time  t,  a  real-time  RGS  will  imply  a  real-time  handshake 
communication  scheduler ,  with  the  same  time  performance  (see  the  Appendix) . 
It  is  interesting  to  note  (as  we  show  in  Section  3)  that  one  can  implement 
also  a  real  time  RGS  by  a  real  time  distributed  communication  subsystem. 


3.  HIGH  LEVEL  RGS  IMPLEMENTATION  ASSUMING  A  REAL-TIME  HANDSHAKE 
COMMUNICATION  SYSTEM 

3.1  The  Algorithm 

Our  implementation  of  a  probabilistic  real  time  RGS  is  as  follows: 

The  granting  processes  i  are  always  willing  to  communicate  only 
to  the  requesting  processes  in  the  set  S^  which  have  rights  to  resources 
p(i)  (as  defined  in  the  Introduction) .  The  requesting  processes  are  willing 
to  communicate  only  to  those  granting  processes  whose  resources  they  want  (or 
have  been  allocated) .  By  communication  here  we  mean  a  handshake  communication. 
We  shall  assume  here  the  existence  of  a  DCS  with  e-error  response  T(e),  as 
in  the  Appendix. 

We  may  view  the  actions  of  the  requesting  processes  time-sliced  in 
rounds,  where  each  round  is  a  minimal  time  interval  in  which  i  communicates 
at  least  once  with  all  k  of  the  resource  controlling  processes  of  the 
resources  which  i  wishes  to  obtain. 

The  granting  processes  do  forever  the  following  grant  algorithm  which 


is  a  loop,  a  single  execution  of  which  is  called  a  grant  phase t 
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Grant  Algorithm 
for  process  i  €  R 


Do  forever 


begin 

11] *  Do  a  handshake  communication  with  anyone  of  the  requesting 

processes  in  and  get  their  priorities  (in  £  steps) . 

12] ,  Probabilistically  select  jCS^,  in  6  steps.  (The  values  of 

the  priorities  determine  the  probability  of  each  requesting 
process  to  be  selected  as  determined  in  Section  3.2.) 

[3] ,  On  first  handshake  with  the  selected  process  j,  say  "yes"  to 

j  allocating  your  resource  to  j.  (6  steps) 

[4] .  For  2  6  steps,  the  granting  process  says  "no"  to  any  requesting 

process  but  j  in  any  handshake  and  says  "yes"  to  j  on  any 
communication . 

15].  On  handshake  with  any  other  process  than  j,  the  granting  process 
i  says  "no".  On  first  handshake  communication  with  j,  the 
granting  process  i  says  "no"  to  j ,  indicating  that  resource 
p(i)  has  been  withdrawn  from  j  and  ending  the  grant  phase. 

(6  steps) . 

[6],  Wait  for  Iwj  steps  where  w  is  randomly  chosen  from  [0,66']. 
end 


In  the  above  algorithm  we  fix  parameters  6=  fT(e/2v)/r  .  1  and 

man 

6*  =  1 6 (r  /r  .  ) ] .  Hence  6  steps  of  any  tame  process  contain  at  least 
max  man 

time  T(e/2v)  and  the  maximum  time  duration  of  6  steps  is  equal  to  the 
minimum  time  duration  of  £'  steps.  Thus  the  maximum  possible  length  of  the 
random  wait  is,  at  least  the  time  length  of  the  rest  of  the  stages  of  the 
grant  phase.  Note  that  stages  [1],  [3]  and  [5]  may  take  more  than  6  steps 
(with  very  low  likelihood) .  This  is  taken  into  account  in  the  analysis  of 
performance  of  the  algorithm. 
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3.2  Probabilistic  Selection 

We  give  here  a  very  simple  implementation  of  probabilistic  selection 

of  one  out  of  <v  processes  (using  their  priorities)  in  0(v)  steps  as 

required  in  phase  2  of  the  algorithm  in  Section  3.1.  This  implementation 

can  easily  be  improved  to  O(log  v)  steps  (see  [Reif,  Spirakis  1982]). 

Suppose  that  each  resource  allocator  i  has  just  a  random  number 

generator  drawing  uniform  numbers  between  0  and  1.  Let  tt^  ,tt^  , . . .  »1Tvi  (for 

v'<v)  be  the  processes  requesting  the  resource  of  i  at  the  current  time 

and  let  P.  ,  P.  ,...,P.  be  their  priorities.  Let  h (x)  =  I.  ,  P.  , 

lTri  i7T2  aV  3=1  17rj 

for  any  x  in  {o,l,2,...,v*}.  To  implement  the  selection  process  of  stage 

[2]  we  do  the  following: 

[2.1]  draw  a  random  number  n  in  [0,1]. 

[2.2]  find  the  process  name  t  for  which 

h(x-l)  ^  h (x) 
h(v')  n  h(v’) 

Note  that  stage  [2.1]  takes  one  step  and  stage  [2.2]  takes  0(v)  steps  since 
we  have  to  evaluate  and  compare  2  partial  sums  each  step.  Since 

h(x)  =h(x-l)  +P.  for  any  x  in  {l,...,v*},  the  current  partial  sum  can 

17T 

X 

be  evaluated  from  the  previous  partial  sum  by  a  single  addition. 


4.  REAL  TIME  IMPLEMENTATION  BY  USE  OF  FLAG  VARIABLES 

4.1  The  Algorithm  for  the  Case  of  Equi-Speed  Processes 

For  simplicity,  we  shall  temporarily  assume  here  a  fixed  time  instant 
tQ>0  such  that  for  time  t>tQ  al*  processes  are  executing  at  the  same 
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r 


speed.  (Section  4.2  drops  the  assumption  of  equi-speed  processes.)  How¬ 


ever,  for  times  t <  t^  in  the  past,  the  processes  may  be  asynchronous  and 
so,  at  t^tQ  the  execution  of  their  programs  in  time,  though  proceeding 
with  equal  speed  for  all  processes,  may  be  shifted  (in  an  adverse  way) 
relative  to  each  other. 

The  communication  between  granting  and  requesting  processes  is  done 
here  by  flag  variables.  To  read  one  flag  requires  one  of  the  process  steps. 

In  case  of  priorities,  the  flags  are  allowed  to  have  rational  values  between 
0  and  1,  initially  0.  The  flags  P  indicate  the  priority  of  user  j  with 
respect  to  resource  i.  In  the  simple  case  of  equal  priorities  all  flags 
need  only  be  boolean.  Each  granting  process  i  has  for  each  requesting 
process  j  a  special  flag  F^_.  whose  value  indicates  if  the  resource  p  (i) 
is  allocated  to  j.  If  j  reads  F„  and  finds  it  0,  then  it  understands 
that  it  lost  the  resource.  The  granting  processes  execute  forever  the  following 
loop,  called  a  grant  phase : 

Grant  Algorithm 
of  Granting  Process  i €  R 

Do  forever 
begin 

[1) .  Read  the  priority  flags  of  the  requesting  processes  in  the  set  S^. 

[2) .  Probabilistically  select  each  of  the  requesting  processes  j € 

according  to  their  priorities  (see  Section  3.2). 

[3] .  Set  the  flag  F^j  to  1  indicating  that  resource  p(i)  has  been 

allocated  to  process  j . 

[4]  Wait  for  cv  (non-operative)  steps. 

[5)  Set  the  warning  flag  I^j  to  1  to  indicate  to  j  that  he  will 

loose  the  resource  after  at  most  2cv  steps.  Wait  2cv  steps. 

[6]  Set  F±j  to  0  (indicating  that  i  removes  the  resource) . 

Erase  the  warning  by  setting  L. .  to  0. 
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[7]  Wait  for  w  steps  where  w  is  a  random  integer  selected 
uniformly  from  [0,5cv]. 

end 

Stages  [1],  [2]  are  required  to  take  exactly  cv  steps  each,  where  c  is 
a  small  constant  whose  exact  value  can  be  determined  by  counting  the  maximum 
number  of  steps  of  the  granting  process  per  requesting  process  in  the 
stages  [1],  [2],  [3]. 

The  grant  phase  takes  a  random  number  of  steps,  uniform  in  the  set 
{ 5cv , 5cv+l , . . . , 10cv} . 

Each  user  process  j  €  U  executes  continuously  the  following  loop,  a 
single  execution  of  which  is  called  a  round. 


Do  forever 


begin 

[1] .  Set  p^j  to  1  for  each  resource  p(i)  requested  by  user  j. 

(cv  steps) 

[2] .  Poll  for  cv  steps  to  see  which  resources  have  been  awarded  to 

user  j.  User  j  considers  the  resource  p(i)  awarded  only 
if  p(i)  has  been  both  allocated  (F. .  =1)  and  not  yet  warned 


13).  If  all  resources  requested  by  j  are  awarded  use  them  for 
p  steps. 

end 


(See  also  Figures  1  and  2.) 


award 

resource 
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start 

warning 
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random 
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Figure  1;  A  pharc  of  a  grant  process. 
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Fioure  2:  A  round  of  a  requesting  process 


-15- 


4.2  The  Flags  Implementation  of  the  RGS  for  the  Case  of  Asynchronous, 
Tame  Processes 

Grant  Algorithm 

for  i£R,  for  asynchronous  case 

It  is  the  same  as  in  the  case  of  equi-speed  processes.  However,  the  stage 
lengths  are  modified  as  follows: 


Stage 

[13  s 

takes 

c'v  steps 

Stage 

[2]  : 

takes 

c'v  steps 

Stage 

[31: 

1  step 

as  in  equi-speed 

case 

Stage 

[4]  : 

takes 

c'v  steps 

Stage 

[5j: 

takes 

2c'v  steps 

Stage 

[71: 

choose 

a  random  integer 

w  £  [0 , 5c"v] 

where 


(r*  V 


The  round  of  j  €  U  in  asynchronous  case : 

Same  actions  as  in  equispeed  case.  The  stage  lengths  in  steps  are  cv, 
cv  and 

.  . .  min 

U  <  (cv-1)  - -  , 

max 

for  stages  [1],  [2],  13],  respectively. 


--v  t  — 


Note  that  in  the  equispeed  case  assumed  here,  the  time  is  a  constant 
multiple  of  the  process  steps.  The  power  of  the  adversary  is  thus  restricted 
to  only  a  possibly  malicious  initial  relative  shift  of  the  program  counters  of 
the  various  processes. 

lemma  1.1.  For  y < cv  -  l,  it  is  impossible  for  the  user  j  to  conclude 
that  it  has  got  all  resources  and  actually  some  of  the  resources  to  have  been 
removed. 

Proof.  Since  the  polling  time  of  j  lasts  only  cv  steps ,  by  the 
time  user  j  concludes  that  the  last  resource  is  allocated  to  j,  the  first 
allocated  resource  can  at  most  be  in  the  middle  of  the  warning  period  (and 
hence  not  removed  yet).  Since  U < cv >  1,  j  has  then  enough  steps  at  its 
disposal  to  use  the  resources,  before  the  first  allocated  resource  is  removed.  D 

lemma  1.2.  The  probability  that  user  j  will  get  a  particular  resource 
in  its  current  round  is  <  1/v  for  the  worst  case  oracles. 

Proof.  Consider  the  subclass  of  oracles  ^  which  put  maximum  contention 

on  the  system.  These  oracles  give  a  worst  case  of  the  response  time,  since 

contention  cannot  decrease  the  response  time.  However,  in  this  case,  the 

probability  that  user  j  will  get  a  particular  resource  in  its  current  round  is 

at  best  equal  to  the  probability  that  j  is  going  to  be  selected  by  the  resource 
allocator,  so  it  is  not  more  than  1/v.  o 

Recall  tQ  is  the  time  instant  at  which  the  processes  became  synchronous. 

Let  t  be  any  time  instant  after  t,..  Let  resources,.  (j)  ■  {p, , . . .  ,p.  .  } , 


where  k'  ^k,  for  a  particular  requesting  process  j£R  and  let 


i„,...,i  ,  be  the  resource  allocators  associated  with  those  resources. 

1  k 

In  the  following  we  consider  a  time  interval  I  starting  at  t^  during 

which  the  set  resources  (j)  for  t£l  is  equal  to  resources  (j).  Let 

1  tl 

T  be  a  complete  description  of  the  system's  history  up  to  time  t 
fcl  1 

(including  the  probabilistic  choices  of  the  processes  up  to  that  time) .  Let 

t  (where  l<m<k*)  be  the  first  time  after  t,  at  which  the  allocator 
m  ,  1 

i  starts  a  random  wait  stage.  Let  t  be  the  maximum  of  all  t  's  for 
m  Mm 

m=l,...,k'  and  let  t£  be  the  maximum  of  the  time  instances  at  the  ends 

of  the  first  grant  phase  of  processes  i  ,...,i  ,  after  time  tM>  The 

time  interval  (t  ,t  ]  is  called  a  session  1  of  processes 
X  s 

(j/i^/ij'*  •  •  '^jji  ^  * 

Let  g^  (I)  be  the  probability  that  the  process  j  will  get  all  its 

resources  in  the  session  Z,  given  any  history  T  . 

1 

Note  that  a  session  is  at  most  two  grant  phases  of  any  resource 

allocator,  because  processes  are  equispeed.  Note  also  that  after  t„  the 

effect  of  the  history  F  is  completely  counteracted  by  the  random  waits 

ri 

done  by  the  processes. 


DEFINITION.  Let  g.lt  ,t  )  be  the  probability  that  process  j  will 

3  M  5 

get  all  its  resources  during  the  interval  (t„,t_),  given  any  history  T  . 

M  5 

Obviously  g(t„,t_)  <g.(E).  Note  that  there  is  at  least  one  complete 
3  M  s  3 

round  p  of  process  j  during  a  session  I  ,  such  that  R  starts  after 


tu.  Let  e  be  the  event  "the  flag  P.  .  of  user  j  is  seen  by  the 
Mm  l 

m 

resource  allocator  i  in  the  round  R  and  during  (t„,t_)  and  j  is 

m  ms 

selected  by  i  Then  g .  (t  ,t_)  >  Prob(n]'  E  ) . 

m  3  M  s  m*±  in 
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LEMMA  1.3.  The  events  E1<...'Ek,  are  independent. 

Proof.  Fix  a  time  1 6  (t..,t„).  By  time  t,  all  allocators  have 
— —  M  S 

executed  at  least  a  random  independent  wait  stage.  The  length 
of  the  wait  stage  is  uniformly  randomly  chosen  to  take  any 

integer  value  from  0  up  to  the  length  5cv  of  all  the  other  stages  of  a  grant 
phase.  Thus,  at  time  t  any  allocator  m  is  at  each  step  of  the  non-wait 
part  of  4-ts  grant  phase  with  equal  probability.  a 

COROLLARY  1.3. 


g. (t  .t  )  >  ProbtE  ) • . . . • Prob (E  , ) 

IMS  1  K 


Proof.  By  the  independence  of  events  E^,  m=l,...,k'  as  proven  in 


Lemma  1.3. 


lemma  1.4.  For  any  m€{l,...,k'} 


prob (E  )  >  77 — 
m  lOv 


Proof.  Let  E'  be  the  event  "the  flag  P.  .of  user  j  is  seen 

-  m  lO 

n 

by  i  in  the  round  R  and  during  (tw,t_) . "  Then  Prob(E  given  E’)>l/v 
m  ms  in  in 

since  i  selects  one  out  of  at  most  v  processes  with  equiprobability  and 
m 

j  is  one  of  them.  Also,  prob(E^)  =prob(the  start  of  R  fells  into  the 
first  stage  of  a  grant  phase  of  i  during  (t„,t  ))  =  ratio  of  length  of 


m 


first  stage  divided  by  total  length  of  the  grant  phase  of  i  (by  Lemma  1.3) 

xn 

But  the  total  length  of  any  grant  phase  is  at  least  5cv  and  at  most  lOcv 
and  the  length  of  first  stage  is  exactly  c  hence 


w  rv 

prob  (E‘ )  >  77: — 
*  m  lOcv 


10 
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AlSO, 

prob(E  )  ^  prob (E1 )prob (E  given  E‘) 
*  m  m  m  m 

>  1  1 
>  10  '  v 


□ 


By  Corollary  1.3  then 
COROLLARY  1.4. 


a.  (t 
1 


M*  tS) 


1 

k  ' 

( lOv) * 


1 

(10v)k 


Hence 


9i  (I) 


1 

(10v)k 


since  k '  <  k. 


Also ,  note  that 

s(v)k 

due  to  Lemma  1.2. 

Let  u  be  the  number  of  sessions  required  for  user  i  to  be  granted 

all  its  k  resources  in  some  round,  given  that  i  starts  requesting  them 

at  time  t  and  assuming  any  history  T  and  oracle  <V.  By  the  Corollary 

1  tl 

1.4  and  Baye's  formula, 

I  1  \n''1  1 

Prob(u=m)  <  11  -  - r~  I  - r 

\  (lOv) K  /  (v) 

If  u { c }  is  the  least  number  such  that  prob{u>u(e)  then 


u  (€) 


loq(e/(10)k) 

\  do v)K; 
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It  is  easy  to  show: 

PROPOSITION  1.  For  every  n€N, 


By  Proposition  1,  then 

k  m  k  l 

'  u(e)  <k*(10v)  log  —  =  0(kv  log  — ) 

Since  each  session  takes  <20cv  steps,  we  have 
Prob{y,  ^  20cv  u(e)}  ^  1  -  e 
implying  e-error  response 

k+1  ] 

Yk(c)  =  0 (kv  log(i)) 

and  mean 

y  =  0(kvk+1) 

k 

COROLLARY  1.5.  In  the  case  of  equispeed  processes,  our  flag 

implementation  of  RGS  has  real  time  response,  with  e-error  response 

k+1  l  -  k+l 

y  (C)  *  0(kv  log{^))  and  mean  y  =  0(kv  ). 

K  c  K 

5.2  The  Case  of  Asynchronous  Tame  Processes 

Our  analysis  for  the  case  of  asynchronous  tame  processes  parallels  that 
of  the  equispeed  case. 

lemma  2.1.  For  v  <  (cv-l) (r  .  /r  ) ,  it  is  impossible  for  the  user 

mm  max 

j  €  u  to  conclude  that  it  has  got  all  resources  and  actually  some  of  the  resources 
to  have  been  removed. 
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Proof.  The  polling  time  of  i  can  at  most  be  cv  r  ,  since  it 
-  max 

includes  just  cv  steps  of  i.  Each  resource  allocator  waits  2c' v  steps 

after  setting  its  warning  flag  to  1  and  then  it  removes  the  resource.  Since 

c*  =(r  /r  .  )*c  we  have  that  c' ’v  steps  of  a  resource  allocator  are  at 
max  min  r 

least  c'v  r  .  time  which  is  at  least  cv  r  time.  Hence,  by  the  time 
min  max 

j  concludes  that  the  last  resource  has  been  allocated  to  him,  the  allocator 

for  the  first  resource  granted  can  at  most  be  in  the  middle  of  its  warning 

period  (in  terms  of  steps).  The  maximum  time  corresponding  to  y  steps  is 

y  r  =  (cv-l)r  .  and  the  minimum  time  which  corresponds  to  the  remaining 
max  mm 

half  steps  of  the  warning  period  is  at  least  c’v  r  .  * cv  r  >  (cv-l)r  .  . 

c  ”  min  max  min 

So,  j  has  enough  time  at  his  disposal  to  use  the  resources,  before  the  first 
allocated  resource  is  removed.  O 

As  in  Lemma  1.2,  we  have: 

lemma  2.2.  The  probability  that  user  j  will  get  a  particular 
resource  in  its  current  round  is  <  1/v  for  the  worst  case  oracles. 

Let  t^  I*t  .  tM,  tg,Z,  {p1,...,Pk,},  j.  I,  gi(I)  and  g^t^tg) 
just  as  defined  in  Section  5.1. 

A  crucial  difference  from  5.1  is  that  now  a  session  is  at  most  two 
grant  phases  for  at  least  one  allocator  and  not  necessarily  for  all  of  them. 
Again,  g.  (t„,t_)  <  g. (I). 

IMS  1 

Note  also  that  the  minimum  time  duration  of  a  grant  phase  is 

2 

(5c'v  +  5c"v)r  .  =  5cv(r  +  (r  /r  ,  ) )  and  the  maximum  time  duration  of 

min  max  max  min 

a  round  of  a  requesting  process  is  now  (2cv  +  y)r  <  (2cv+cv(r  .  /r  ))r _ 

max  min  max  max 

*  cv(2r  +r  ,  ).  This  implies  that  a  grant  phase  of  any  allocator  contains 
max  min 

at  least  2  rounds  of  any  requesting  process  and  hence  there  is  at  least  one 
complete  round  R  of  process  j  during  Z  and  after  t^. 


Again 


-23- 


k 1 

g.  (t„,t  )  >Prob(fl  ,  E  )  with  E  defined  as  in  5.1. 
l  M  s  m=l  m  m 

LEMMA  2.3.  The  events  E  , _ .E^,  are  independent. 

Proof.  Fix  a  t€  (t„,t„).  Since  t  >  t..,  by  time  t  all  allocators 
"  MS  M 

have  each  executed  one  (or  more)  random  independent  wait  stages.  The 

number  of  steps  of  a  wait  stage  is  a  random  integer  chosen  uniformly  from  0 

2 

to  5c"v,  where  c" =  (r  /r  .  )  *c.  Hence  the  minimum  time  duration  of  a 
t  max  min 

wait  stage  is  at  least  5vc”r  .  =5vc(r  /r  .  )*r  =  5vc’r  =  the 

min  max  mm  max  max 

maximum  time  duration  of  the  rest  of  the  stages  of  the  grant  phase.  So,  in 
any  case,  the  random  wait  can  completely  cover  the  length  of  the  rest  of  the 
stages.  So  at  time  t >  t  any  allocator  m  is  at  any  step  x^  with  equal 
likelihood,  independently  of  other  allocators.  o 

As  in  Corollary  1.3,  we  have 


COROLLARY  2.3. 


k' 

g. (t  ,t  )  >  n  Prob(E. ) 

1  M  £>  .  1 


LEMMA  2.4.  For  any  m€{l,...,k'} 


prob{E  }  ^ 
m 


r  . 
min 

r 

max 


1 

v 


Proof.  Let  E'  be  the  event  as  defined  in  Lemma  1.4.  Again, 
—  m 

prob(E  /E’)  >  1/v  ar!d  prob(E')  *  ratio  of  length  of  first  stage  divided 
mm  m 

by  total  length  of  the  grant  phase 


— x  r 
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c' vr  . 
min 


(5c’v+5c"v)r 

max 


1 


r  . 
min 

r 

max 


and  since  Prob(E  )  >  Prob(E')  •  Prob(E  /E') 
m  m  mm 


the  lemma  follows. 


Hence,  by  Corollary  2.3. 
COROLLARY  2.4. 


□ 


Let  u  be  defined  as  in  case  of  equi speed  processes. 

By  following  same  steps  as  in  that  case,  we  get 

u(e)  <  k(Av)k  log  —  =  o|kvk  log^jj 

A  session  is  at  most  two  grant  phases  of  at  least  one  allocator. 

Therefore  the  time  length  of  a  session  is  bounded  by  (5c'v  +  5c"v)r  ,  so 

max 

we  have 

Prob{y.  5v(c'  +c")r  *u(E)}  >  1  -  e 

k  hV  max 


COROLLARY  2.5.  Our  flag  implementation  of  RGS  in  the  general  case  of 
tame  asynchronous  processes ,  has  real  time  response  with 

yk<e)  -  o|kvk+1  log(^)j 
and 

Yk  -  0(kvk+1) 


’X  T 
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5.3  Analysis  of  our  RGS  which  Uses  a  Handshake  Communication  System. 


By  the  stated  properties  of  DCS , 


PROPOSITION  3.1. 


Probca  round  length  is  at  most 


lemma  3.2.  The  ■probability  that  a  particular  requesting  process  i 
will  get  a  "ues"  answer  in  a  handshake  in  stage  3  is  <  1/v  for  the  worst 
case  oracles. 


Proof.  Consider  again  the  class  of  oracles  S?  putting  maximum 
contention  in  the  system. 


o 


Let  t  ,  t„,  t_,  r  ,  Z,  g.  (Z)  and  g. (t„,t_)  be  just  as  defined  in 
1  M  S  t^  1  IMS 

Section  5.1.  Again,  g.  (t„,t_) < g.  (Z) . 

l  M  S  =i 

Let  be  now  the  event  "a  requesting  process  j  gets  a  "yes" 

answer  in  a  handshake  with  allocator  i  in  the  interval  (t  ,t_)  and  in 

m  Mb 

'  k' 

the  first  round  R  of  j  after  t..."  Note  that  g.  (t„,t_)  >Prob(fl  ,  E  ). 

M  i  M  S  m=l  m 

We  show  again  that  the  events  E  are  statistically  independent,  as 

m 

in  the  Proof  of  1.3.  Again  we  observe  that  the  length  of  a  random  wait  has 

a  nonzero  probability  of  completely  covering  the  length  of  the  rest  of  the 

stages  in  a  grant  phase.  The  length  of  a  random  wait  is  randomly  chosen 

from  [0,65']  So  its  maximum  duration  is  at  least  65'  r  .  * 

min 

6  5(r  /r  .  )r  .  *  65  r  ■  the  maximum  time  duration  of  the  rest  of  the 

max  min  min  max 

grant  phase  stages.  So,  Lemma  1.3  holds  again,  hence 


wv  * 


k' 

TT  Prob  (E  ) 
_ i  m 


COROLLARY  3.3. 
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LEMMA  3.3.  For  any  m€  {l, . . .  ,k' } 


i  r  •  i 

1  min  1 


r 

max 

r  . 
min 


r  v 
max 


Prob(E  ) 
m 


6  1 


Proof.  Let  E'  be  the  event  "the  handshake  of  processes  j  and  i 
-  m  ro 

will  take  place  at  the  first  stage  of  the  grant  phase  of  im»  in  the  first 
round  R  of  j ,  in  the  interval  [tu,t_l" .  Then  Prob(£  |e')^1/v  due  to 
probabilistic  selection  of  requesting  processes.  Also  prob(E^)  =  prob 
(the  start  of  R  falls  into  the  first  stage  of  a  grant  phase  of  i 
during  time  interval  (t.,  ,t_)  =  ratio  of  length  of  the  first  stage  divided 
by  total  length  of  the  grant  phase,  because  by  tM  process  i  has 
executed  at  least  one  random  wait  (after  t^)  and  hence  the  start  of  R 
will  be  any  time  instant  of  a  grant  phase  of  i^  with  equal  probability, 
independent  of  the  history  T  .  Hence, 


^  min  length  of  stage  1 
pro  “  max  length  of  grant  phase 


m 


6r  . 
min 


(66+66' )r 


max 


So,  prob(E  )>Prob(E  ).prob(E  /E  ,) 
in  in  to  m 


(i  +  ^«\ 
'  rmin' 


.( 

L  + 

^min' 

min  1 

r  v 
max 


min 


max 


a 


Due  to  Corollary  3.3,  Lemma  3.3  and  Lemma  3.2  we  get 


COROLLARY  3.4. 
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■jYK..rf< 


Prob^Y,,  (time  duration  of  a  session) 


■d)l 


5*  Prob  (each  session  contains  at  least  one  complete  round  R 
and  u<u(e/2)} 


because  the  "length  of  a  round"  distribution  is  determined  by  the  underlying 
DCS  implementation  independently  of  the  number  of  rounds  needed  for  a  process 
to  get  all  its  k  resources.  So 

ProbjYk,.,/  12(Y  *  7“)  WT(fe)  "(f)  j 

implying 

V£>  ■  °(Y(^)“(I))-  °(kvk  l°9(r)Y(fc)) 


in 
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which  has  mean 

Yk  =  0(kvk  T  log  v) 

2  -  2 

Using  T(e)  =0(v  log(l/e))  and  t  =  0(v  )  as  given  in  [Reif,  Spirakis, 
1981]  we  get 

Ve)  =  °(vk+2  log(i)  log(f )) 

and  , 

Yk  =  0(kvk+2  log  v) 

Note  that  our  response  for  the  flag  implementation  is  slightly  better 
than  those  based  on  a  handshake  communication  system,  since  there  is  no 
uncertainty  about  flag  communication  in  each  round.  However,  when  processes 
are  not  tame,  the  correctness  of  the  implementation  by  flags  may  be 
violated,  while  the  correctness  of  the  implementation  by  an  underlying  DCS 
will  be  preserved  (because  of  the  handshake  communication  which  accompanies 
allocation  or  deallocation  of  a  resource)  given  that  the  correctness  of 
the  underlying  DCS  is  not  violated  when  processes  are  not  tame. 
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JiPPENDIX 

Distributed  (Handshake)  Communication  Systems  (DCS) 

Suppose  that  each  process  has  a  special  resource  called  channel  which 
can  be  in  one  of  two  states  open ,  closed.  A  handshake  of  two  processes  i, 
j  in  time  t  is  a  combination  of  processes  states  at  time  t  so  that 
both  channels  of  i  and  j  are  open  at  the  same  time. 

Successful  direct  corrmunication  is  a  handshake  of  at  least  1  step 
overlap  of  both  processes  so  that  the  handshake  relation  is  a  matching.  At 
any  instant  t  no  process  is  allowed  to  be  handshaking  with  more  than  one 
other  process.  During  the  one  step  overlap,  a  message  can  be  transmitted 
from  one  process  to  the  other.  The  problem  is  usually  to  synchronize 
processes  (via  a  distributed  scheduler)  so  that  they  can  handshake  at 
their  will,  given  that  the  means  of  synchronization  is  some  low  level 
construct  (a  message  system,  buffered  communication,  shared  variables  or 
flags)  which  does  not  guarantee  the  handshake  property  if  used  in  an 
unsophisticated  way.  A  distributed  scheduler  is  called  real  time  if  it 
has  the  property  that  if  two  processes  i,  j  are  willing  to  handshake 
mutually  for  at  least  a  constant  time  interval,  then  they  will  actually 
achieve  successful  direct  communication  during  that  time  interval  with 
arbitrarily  small  probability  of  error. 

Formally,  let  T(E)  be  the  smallest  real  number  such  that  if  two 
processes  i,j  are  mutually  willing  to  handshake  for  at  least  T(E) 
time,  then  they  will  actually  succeed  in  1  step  overlap  of  open  channels 
during  that  time,  with  probability  >  1-e.  T(e)  is  called  the  E-error 


- ■>»  T” 
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response  of  the  handshake  algorithm.  The  mean  response  T  of  a  handshake 
algorithm  is  the  maximum  (over  all  adverse  speed  schedules  of  tame  processes 
and  overall  adverse  communication  requests  subject  to  restrictions  stated 
in  the  Introduction)  of  the  mean  time  needed  for  two  processes  to  handshake, 
from  the  time  instant  they  start  to  be  mutually  willing.  A  real  time 
probabilistic  scheduler  has  T(e)  depending  only  on  v  and  not  on  any 
othes  global  measure  of  the  communications  graph.  (v  is  a  fixed  upper 
bound  on  the  out-valence  of  the  dynamic  communication  willingness  digraph 
at  any  time  instant  t).  We  also  require  T(e)  to  increase  at  most 
linearly  with  1/E.  Note  that  such  a  scheduler  has  T  also  depending  only 
on  v. 

The  handshake  problem  has  been  given  some  attention  in  literature 
[Schwarz,  79],  [Francez,  Rodeh  80],  [Frances,  81],  [Reif,  Spirakis  81], 
and  [Reif,  Spirakis  82A] . 

For  Section  3  we  require  a  Distributed  Communication  System  (DCS)  as 
defined  above  with  a  distributed  real  time  probabilistic  scheduler.  We 
also  require  the  DCS  to  have  the  following  property: 

If  a  process  i  is  willing  to  communicate  with  k<v  processes  for 
at  least  time  (e)  and  if  they  are  also  willing  to  (handshake)  communi¬ 
cate  with  i  during  that  interval,  then  the  probability  that  i  will  be 
able  to  communicate  with  all  of  them  (in  some  order)  within  T(e),  is 
>(l-e)V.  Such  a  real  time  DCS  was  implemented  in  [Reif,  Spirakis  81]  with 
E-error  response 

T (c)  »  0(v2  logll/c )) 

and  mean 

T  «  0(v2) 
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